The commoditization of silicon chips has permitted the integration of “intelligence” (in the form of a processor or microcontroller executing program code) and “connectivity” (in the form of some kind of network interfacing capability) into many household or office appliances such as a remote controls, televisions, telephones, security systems, lights and/or lighting systems, music and/or video players, recorders, and/or receivers, thermostats, smoke detectors, garage door openers, meters, etc. Unfortunately, a number of different networks have come into existence for permitting such household devices to communicate (e.g., X10, ZigBee, Z-Wave, IEEE 802.11 based networks and Universal Plug-n-Play (UPnP)) leaving the home owner (or IS manager) with the problem of “bridging” between networks so that an appliance connected to one type of network can communicate with another appliance connected to another type of network.
FIG. 1 shows a schematic depiction of the problem which may be viewed as the network environment within a home or office. Here, a number of different appliance networks 101, 102_1, 102_2, . . . 102_N are observed each with their own associated appliances. Specifically, UPnP network 101 communicatively couples appliances 103_1 through 103_4; X10 network 102_1 communicatively couples appliances 104_1 through 104_3, Z-Wave network 102_2 communicatively couples appliances 105_1 through 105_4; and 802.11 network 102_N communicatively couples appliances 106_1 through 106_4. Here, it should be understood that the term appliance is meant to include other electronic devices besides those listed above including (but not limited to) personal computers (including laptop/notebook computers), personal digital assistances (PDAs) and cell phones. An appliance network is a packet based network that communicatively couples appliances.
FIGS. 2 and 3 show some prior art approaches for bridging a UPnP network to a number of non UPnP networks. According to the approach of FIG. 2, the bridging is performed by essentially making every appliance UPnP compatible as well as compatible with its other associated non UPnP network. For instance, compare appliance 104_1 of FIG. 1 with appliance 204_1 of FIG. 2. Appliance 104_1 of FIG. 1 only has a single network interface 108_1 so that it can communicate through the X10 network 102_1. By contrast, referring to FIG. 2, appliance 204_1 now has two interfaces: a first network interface 208_1 for the X10 network 202_1 and a second network interface 209_1 for the UPnP network 201.
Embedding all of the appliances 204_1 through 204_3, 205_1 through 205_4, 206_1 through 206_4 with dual network capability as depicted in FIG. 2 allows each of these appliances to communicate both with its respective local network 202_2, 203_2 or 202_N and the UPnP network 201. A problem with this approach, however, is that is has the potential to raise the complexity and/or cost of these appliances (in terms of additional or more advanced hardware (e.g., additional physical interface components and/or memory and/or higher performance processing cores) and/or software (e.g., a pair of executable protocol stacks: one for each the networks).
FIG. 3 shows another prior art approach that embraces the use of gateways 310_1, 310_2, 310_N having respective translator software 311_1, 311_2, 311_N. Here, it is pertinent to realize that a network interface to an appliance network interface typically provides a software application programming interface (API) at least for sending commands to specific appliances. For example, if a personal computer (PC) on the X10 network 302_1 (e.g., appliance 304_2) desires to turn on a light that is also connected to the X10 network (e.g., appliance 304_3), software running on the PC 304_2 will issue a command through the API of the X10 network interface 308_2 that identifies the light and the action to be taken (i.e., turning on the light). The software and hardware running on the PC that correspond to the X10 network interface 308_2 then act to construct a packet in the X10 format containing the command. The packet is then sent from the PC 304_2 to the light 304_3 over the X10 network 302_1.
The act of turning on a light connected to the X10 network from a PC becomes more complex, however, if the PC that issues the command is located on another network such as the UPnP network 301 (e.g., PC 303_2_. Specifically, because the PC 303_2 is connected to the UPnP network 301, the PC 303_2 only has a network interface 307_2 with corresponding API for a UPnP network. As such, the PC 303_2 can only issue a command through its UPnP API and send a UPnP packet to gateway 310_1.
A UPnP:X10 translator 311_1 residing on the gateway 310_1 is responsible for comprehending the UPnP command contained in the payload of the packet and translating it into the same command but crafted in the X10 format. That is, the payload of the packet is changed from a command to turn on a specific light scripted in the UPnP format into a command to turn on the same light scripted in the X10 format. Routing and transport layer headers may also need to be changed/removed as well in order to construct a complete, new X10 packet containing the command originally issued by the PC 303_2 on the UPnP network 301. The gateway 310_1 then sends the X10 packet created by the translator 311_1 to the light 304_3 over the X10 network 302_1 and the command is executed.